1. Field of Invention
The invention relates generally to computer systems. More particularly, methods and apparatus for providing a generic contract between an application server and a message provider which allows the message provider to deliver messages to message endpoints (MDBs) residing in the application server independent of the specific messaging style, messaging semantics and messaging infrastructure used to deliver messages. Such a contract also serves as the standard message provider pluggability contract that allows any message provider to be plugged into any application server via a resource adapter.
2. Description of Relevant Art
In modern Enterprise Information Systems (EIS) is formed to include a number of EIS resources. An EIS resource provides EIS-specific functionality to its clients examples of which include a record or set of records in a database system, a business object in an ERP system, and a transaction program in a transaction processing system. Generally, an EIS is formed of a number of interconnected personal computers, workstations, mainframes, and the like along with other devices such as large mass storage subsystems, network interfaces, as well as interfaces to the public telephony systems are interconnected providing an integrated environment in which information may be shared among the various users. Typically, users may be performing a variety of operations, including order receipt, manufacturing, shipping, billing, inventory control, and other operations in which sharing of data on a real time basis provides a significant advantage over, for example, maintaining separate records and attempting to reconcile them later.
The Java 2 Platform, Enterprise Edition (J2EE) provides containers for client applications, web components (based on servlets, Java Server Pages) and Enterprise JavaBeans components. These containers provide deployment and runtime support for application components as well as an integrated view of the services provided by underlying application server for the associated application components. Containers can run on existing systems such as, for example, web servers (for the web containers) application servers, TP monitors, and database systems for EJB containers enabling EISs to leverage both the advantages of their existing systems and those of J2EE. For example, EISs can write (or rewrite) new applications using J2EE capabilities and can also encapsulate parts of existing applications in Enterprise Java Beans (EJB), Message Driven Beans (MDB), Java Server Pages (JSP) or Servlets. IN addition, EIS applications access functions and data associated with applications running on Enterprise Information Systems (EIS).
The J2EE Connector architecture defines standard contracts which allows bi-directional connectivity between enterprise applications and EISs. An architecture for integration of J2EE servers with EISs is referred to as a connector architecture. There are two parts to the connector architecture: an EIS vendor-provided resource adapter and an application server that allows this resource adapter to plug in. The contracts support bi-directional communication between the application server and the resource adapter. (It is well to note that a resource adapter is a system-level software driver that is used by a Java application to connect to an EIS. The resource adapter plugs into an application server and provides connectivity between the EIS, the application server, and the enterprise application. The J2EE Connector architecture defines a standard architecture for connecting the Java 2 Platform, Enterprise Edition (J2EE) platform to heterogeneous EISs.)
Accordingly, the connector architecture defines a set of scalable, secure, and transactional mechanisms (i.e., a set of contracts) such as transactions, security, connection management, that a resource adapter has to support to plug in to an application server that enable the integration of EISs with application servers and enterprise applications. The connector architecture also defines a Common Client Interface (CCI) for EIS access. The CCI defines a client API for interacting with heterogeneous EISs. The connector architecture enables an EIS vendor to provide a standard resource adapter for its EIS. In this way, an application server vendor extends its system once to support the connector architecture and is then assured of a seamless connectivity to multiple EISs. Likewise, an EIS vendor provides one standard resource adapter and it has the capability to plug in to any application server that supports the connector architecture.
Asynchronous message delivery or event notification is a widely used application communication paradigm. Some of the characteristics of asynchronous message-based communication paradigm include a message producer is not directly aware of message consumers (there could be one or more consumers interested in the message). Message delivery is solicited, that is, a message consumer has to express interest in receiving messages. Message producer is not directly aware of message consumers and consequently it produces messages of a constant type Messaging infrastructure stores and routes messages reliably (depending on QoS) to interested messsage consumers. Inherently, the interaction is loosely coupled. The message producer and the consumer do not share any execution context. The message producer generally is not interested in the outcome of message processing by consumers. The message delivery always involves a message routing infrastructure, which offers varying QoS for storing (persistence) and routing messages reliably.
J2EE applications could use two different approaches to interact with a message provider. One approach relies upon the direct use specific messaging APIs to send and synchronously receive messages. Alternatively, any message provider could provide a connector resource adapter which supplies connection objects for use by applications to send and synchronously receive messages using the specific messaging API without requiring any additional contracts (it could use MDBs to asynchronously receive messages via a message provider).
While the above approaches allow a J2EE application to send and receive messages, there is no standard system-level contract to plug-in message providers to an application server, and to deliver messages to message endpoints (MDBs) residing in the application server. Without a standard pluggability contract, an application server (of which there may be m) would have to use special contracts to interact with various message providers (of which there may be n), and a message provider has to do the same to interact with different application servers representing an mxn type problem.
Therefore, there is a need for a standard, generic contract between an application server and a message provider which allows the message provider to deliver messages to message endpoints (MDBs) residing in the application server independent of the specific messaging style, messaging semantics and messaging infrastructure used to deliver messages. Such a contract also serves as the standard message provider pluggability contract which allows any message provider to be plugged into any application server via a resource adapter.